Use of aggregated groups for managing demand response resources

ABSTRACT

A demand response management system which may be used by utilities, independent system operators, intermediaries and others to manage operations of demand response programs relative to customers, clients, participants, and users of outputs from the utilities, independent system operators, and the like. The demand response management system may provide demand response signal propagation and generation from demand response events. There may be an aggregation of customers, clients, participants, users, and the like. The aggregation may be performed and managed by the utility, independent system operator, or the like, before a DR event is initiated and even before a DR signal is generated.

This present application is a continuation-in-part of U.S. patentapplication Ser. No. 13/153,251, filed Jun. 3, 2011, and entitled “ASystem for Using Attributes to Deploy Demand Response Resources”, is acontinuation-in-part of U.S. patent application Ser. No. 13/019,943,filed Feb. 2, 2011, and entitled “Demand Response Management System”,which claims the benefit of U.S. Provisional Patent Application No.61/301,123, filed Feb. 3, 2010, and entitled “Demand Response ManagementSystem”. U.S. patent application Ser. No. 13/153,251, filed Jun. 3,2011, is hereby incorporated by reference. U.S. patent application Ser.No. 13/019,943, filed Feb. 2, 2011, is hereby incorporated by reference.U.S. Provisional Patent Application No. 61/301,123, filed Feb. 3, 2010,is hereby incorporated by reference.

This present application is a continuation-in-part of U.S. patentapplication Ser. No. 13/153,251, filed Jun. 3, 2011, and entitled “ASystem for Using Attributes to Deploy Demand Response Resources”, whichis a continuation-in-part of U.S. patent application Ser. No.12/834,841, filed Jul. 12, 2010, and entitled “A System for ProvidingDemand Response Services”, which claims the benefit of U.S. ProvisionalPatent Application No. 61/271,084, filed Jul. 17, 2009. U.S. patentapplication Ser. No. 12/834,841, filed Jul. 12, 2010, is herebyincorporated by reference. U.S. Provisional Patent Application No.61/271,084, filed Jul. 17, 2009, is hereby incorporated by reference.

BACKGROUND

The present disclosure pertains to utility resources and particularly toassessment and distribution of the resources. More particularly, thedisclosure pertains to beneficial management of resources and theirloads.

SUMMARY

The disclosure reveals a demand response management system which may beused by utilities, independent system operators, intermediaries andothers to manage operations of demand response programs relative tocustomers, clients, participants, and users of outputs from theutilities, independent system operators, and the like. The demandresponse management system may provide demand response signalpropagation and generation from demand response events. There may be anaggregation of customers, clients, participants, users, and the like.The aggregation may be performed and managed by the utility, independentsystem operator, or the like, before a demand response event isinitiated and even before a demand response signal is generated.

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 is a diagram of an interaction between a utility and/orindependent system operator and a demand response resource;

FIG. 2 is a diagram of a utility and/or independent system operatorwhich performs an aggregation;

FIG. 3 is a diagram of an illustrative example of an aggregationconcept;

FIG. 4 is a diagram showing aggregated participants being represented inthe user interface of the demand response management system with afolder structure; and

FIGS. 5-7 are diagrams of screens which show how aggregated participantsmay be referenced and used in a variety of representative reports thatare generated within the demand response management system.

DESCRIPTION

Effective resource is especially critical when communities areconfronted with a scarcity of a resource in question. It may be notedthat “resource” is a term that may have several senses or meanings.“Resource” may refer to energy, commodity, product, load, and so on. Inanother sense or meaning, “resource” such as a demand response (DR)resource may refer to a customer, a user, facility, and so on. In thefirst mentioned sense, it may refer to electricity, water, gas andnatural resources such as oil. A definition of resource may be extendedto include such things such as water quality and air quality. After all,adequate water quality and air quality appear necessary to support aself-sustaining environment.

Resource management, in both senses, may be necessary so that systemscan optimize the use of a limited resource. Currently, there are varioussystems for managing resources in various environments such asbuildings, apartments, industrial facilities, and computing systems.

One mechanism that may be used to encourage customers to reduce demandand thereby reduce the peak demand for electricity may be referred to asdemand response (DR). DR may refer to management of the demand bycustomers in response to supply conditions. For example, electricitycustomers may reduce their consumption at critical times and/or costs inresponse to market prices. These customers may be regarded as DRresources.

DR programs may require that a utility and/or independent serviceoperator (ISO) deliver DR signals to participants via a communicationschannel. The programs may relate to a distribution of resources such as,but not limited to, electricity, water and natural gas.

DR signals may incorporate business level information, such as prices,reliability and shed levels. At some point, from the utility/ISO toloads in a facility, the business level information sent by theutility/ISO should be processed and used to execute a DR strategy andprogram for the facility.

DR programs may take many forms. They may differ from normal rates andtariffs in that the DR programs are designed to allow the utility/ISOtake specific actions to influence the load profiles of facilities thatparticipate in the DR programs at peak consumption times or periods on agrid. The peak consumption periods may cause critical grid reliabilityissues which should be addressed, but they may also trigger economicfactors where the price of electricity or other power commodity reachesa critical level which may be ameliorated by reducing the overallconsumption on the grid during those periods. The critical periods, inwhich the utility/ISO needs to influence a load profile of a facility,may be referred to as DR events.

A manner in which a utility/ISO may influence a load profile of afacility is to send out a DR signal which is specific to the DR event.DR signals may contain information related to business, controllingloads, and so on. There may be an automated DR where the DR signals thatare sent out by the utility/ISO are responded to in an automatedfashion. Loads within a facility may ultimately be affected by DR eventsvia DR signals to which the facility acts upon or responds. The term“facility” may refer to virtually any location in which there are loadsinfluenced by DR events. Where there are such loads may be regarded as a“DR resource”. The term “utility” may be used in a general sense torefer to a utility, independent system operator, service provider, andthe like.

To provide a context for an aggregation approach, the present disclosurereveals an implementation of DR signals within a “demand responsemanagement system” (DRMS) 20 on a diagram of FIG. 1. System 20 andassociated software may be effected and operated with one or morecomputers/controllers (controllers) 11, 12 and respective connections.The DRMS may be a system that is used by utilities/ISO's to manage theoperation of DR programs. A focus of the DRMS may be on the operationalaspects of managing the selection, signaling and monitoring of the DRresources that are participating in DR programs. The DRMS may bespecifically designed to manage operations of automated DR programs.

There may be various types of interactions that might occur between theutility/ISO and a DR resource as part of a DR program. FIG. 1 is adiagram of an example interaction between a utility/ISO 11 and a DRresource (customer) 12. There may be DR signals 13 going fromutility/ISO 11 to DR resource 12. There may be DR resource information14, such as load measurements, going from DR resource 12 to utility/ISO11.

Terms such as customer, client, user, participant, DR resource, and liketerms, may be used, interchangeably or distinct from one another,depending on a context of a pertinent portion of a description or aclaim.

A description of DR signals 13 may be noted. At a highest level, theremay often be some sort of grid condition, be it economic or gridreliability in nature, which triggers a so-called DR event that requiressome sort of interaction between the utility/ISO 11 and its customers12. This interaction may eventually trigger some sort of load controltaking place at a customer's facility. The interaction between theutility/ISO 11 and the customer 12 may be mediated by DR signals 13 andDR resource signals 14, i.e., information such as measurements. Signals13 and 14 may represent communications between utility/ISO 11, and theDR resource or customer 12. Information contained within DR signals 13may dictate where much of the decision-making takes place relative to,for example, in how the initial grid condition, which triggered the DRevent, results in the eventual load control.

A computer or controller may incorporate one or more inputs, aprocessor, a user interface incorporating a keyboard, a display and atouch screen, a memory, external connections such as an internet, one ormore outputs, and so forth. The computer may be utilized with virtuallyall items in and pertinent to FIGS. 1-7.

FIG. 2 is a diagram of an example system 40 showing autility/ISO/aggregator 58 which provides DR signals 32 to a DRresource/aggregator 34 and receives DR resource information 33, such asload measurements, from DR resource/aggregator 34.Utility/ISO/aggregator 58 may also provide DR signals 55 to a DRresource/aggregator 57 and receive DR resource information 56, such asthe load measurement signals, from DR resource/aggregator 57.Utility/ISO/aggregator 58 may further send DR signals to other DRresource/aggregators and receive DR resource information from those DRresource/aggregators. Since an objective of utility/ISO/aggregator 58 isto spread the DR response among several different DRresource/aggregators 34, 57, and so on, in a manner which best suitsbusiness objectives, it is not necessarily in the best interest todirectly pass on the DR signals 13 (FIG. 1) from a utility/ISO 11 to,for instance, the DR resources 34, 57, and so on. Utility/ISO/aggregator58 may instead either pass on some modified form of a general DR signalor perform direct load control with the DR resource/aggregators 34, 57,and so on. If utility/ISO/aggregator 58 is performing direct loadcontrol; then, for instance, DR signals 32, 55 sent to the DRresource/aggregators 34, 57 will not necessarily have the same form asif the DR signals were received from just the utility/ISO 11. On theother hand, if utility/ISO/aggregator 58 passes on information, such asprice and reliability, in DR signals 32, 55 much like the DR signalsreceived from just a utility/ISO 11, then DR signals 32, 55 sent to theDR resource/aggregators may have the same form but differ in contentdepending on how utility/ISO/aggregator 58 determines that the specificDR resources/aggregators 34, 57 should respond, particularly such as interms of DR resource information 33, 56, for instance, such as loadmeasurements.

Utility/ISO/aggregator 58 may treat various DR resources, such asresources 34 and 57, as one DR resource at utility/ISO/aggregator 58, inaccordance with the aggregation approach as discussed herein. Similarly,DR resource/aggregator 34 may also act as an aggregator for DR resources121, and DR resource/aggregator 57 may act as an aggregator for DRresources 122. DR signals 123 and measurement signals 124 may occurbetween DR resource/aggregator 34 and DR resources 121. Likewise, DRsignals 125 and resource information 126 may occur between DRresource/aggregator 57 and DR resources 122. In some configurations, DRresources 121 and 122 may also be aggregators for other DR resources andbe in parent-child relationships. Thus, they may be referred to as DRresource/aggregators 121 and 122. A parent-child hierarchical structuremay continue on as needed or desired relative to an aggregation of theresources.

An “automated demand response” (ADR) may be used in a number ofdifferent customer market segments ranging from the large commercial andindustrial to small commercial and residential. The number of smallcommercial and residential facilities may typically be larger than thenumber of larger commercial and industrial facilities by several ordersof magnitude. With so many potential customers, it can be burdensome forthe operators of the ADR programs to have to deal with all of them asindividual entities within the demand response management system.

In addition, there may be customers such as big box retailers that havea number of locations which the retailers need to manage as part of asingle portfolio of resources.

The present approach may simplify the management of large numbers ofcustomers by facilitating a creation of aggregated customer groupswithin the DRMS where each group can be treated as a single entity forthe purposes of managing and monitoring their participation in the ADRprogram. The approach may allow for arbitrary levels of aggregationwhere each node in an aggregation tree can be treated as a singleentity.

In some systems, the term “aggregator” may refer to an entity separatefrom the utility. That kind of aggregator may receive a DR signal fromthe utility and then have to determine the customers in its portfoliothat the aggregator needs to group, control and/or determine the ones tosend signals. Such approach is not necessarily efficient and effective,particularly in cases of numerous DR resources.

In the present system, “aggregator” may be regarded as part of theutility. Aggregation may be managed at the utility before a DR event isinitiated and a DR signal is even generated. A utility operator may useaggregated groups to help in the decision-making process of whichresources to send a DR signal to, but also help in propagating thesignal itself because if the operator dispatches to a single aggregatedgroup then the signal would go to all of the resources in the group. Ifthe utility has “aggregation” functionality in its system then there isnot necessarily any need for a separate “aggregator” entity, thusresulting in a more streamlined and efficient demand response managementsystem. DR resources may also have aggregation capability orfunctionality.

In the case of issuing DR events, the operator may be able to issue anevent to an aggregated entity and the event will automatically bepropagated to each of its child nodes. Likewise, in the case of reports,or the monitoring, an aggregated node may inherit and aggregatevirtually all of the information contained within its child nodes. Forexample, if one were to generate a report on the electrical consumptionof an aggregated node, the report would be the sum of the consumption ofall of its child nodes.

Within the DRMS may be a concept of a participant (i.e., customer or DRresource) which is an entity that may participate in a DR program. Theparticipant may be the entity that is assigned to DR programs and mayreceive DR signals from the DRMS. The participant may also be the entityfrom which information such as, for example, electricity consumption iscollected.

FIG. 3 is a diagram of an illustrative example 10 of utilizing anaggregation approach. Participants in the example may be organized intoa hierarchy where each level in the hierarchy is itself anotherparticipant which is in essence an aggregation of the participants belowit. There may be levels 21, 22, 23, and so on, in the hierarchy.

The present approach may implement the structure 10 within the DRMS andadd attributes to the participant models such that each participant canbe classified as a “parent” participant to others and furthermore can beclassified as a “child” to other participants. With respect to FIG. 3,participant “North CA” 25 at level 22 may be a parent to participants“Store 1” 61, “Store 2” 62, and “Store 3” 63 of level 23, and may alsobe a child to participant “Big Box Stores” 24 of level 21. Likewise,“Southern CA” 26 at level 22 may be a parent to participants “Store 4”64 and “Store 5” 65, and also be a child to participant “Big Box Stores”24, and “Central CA” 27 may be a parent to participants “Store 6” 66 and“Store 7” 67, and also be a child to participant “Big Box Stores” 24.

A benefit of treating each of the levels 21, 22, 23 and so on, in theaggregation hierarchy as just another participant is that any of theoperations that can be performed on a single participant may also besupported on any of the aggregated participants. The supported types ofoperations within the DRMS that may apply to both single participantsand aggregated participants may incorporate: 1) An ability to issue DRevents—the effect of this on an aggregated participant may be to issueDR events to each of the children participants; 2) Monitor usageinformation—the effect of monitoring usage information on an aggregatedparticipant may be equivalent to the sum of virtually all of the usageinformation of each of the child participants under the aggregatedparticipant; and 3) The single and aggregated participants may generatereports.

With respect to how aggregated participants are represented in the userinterface of the DRMS, one possible implementation may be using a folderstructure 69 as shown in a diagram of a demand response automationserver (DRAS) participant screen 68 in FIG. 4. Structure 69 showsfolders in a hierarchy of levels 71, 72, 73 and 74. Level 71 may havefolder test3, and level 72 may have folders DEMO, DBP and CPP. Level 73may have folders test35 through test39 and test50 through test54. Level74 may have folders test45 through test49. The folders may representparticipants, clients and/or customers. Various points or nodes thehierarchy may represent places of aggregation.

As noted, each aggregated participant may be shown as a folder withother participants being within that folder. Each of the participants inthe folder may be a single participant or another aggregatedparticipant. For an instance of participant aggregation, participants,test45 through test49, of level 74 may be aggregated into a newparticipant, test35 of level 73.

Structure 69 is shown in a drop down menu 70 of aggregated participants.A program participant may be selected from a list in structure 69. Awindow 75 of screen 68 may be for a “DRAS Customer Interface” (demandresponse automation server customer interface). A “Clients” button 76may be selected and an “aggregation” button 77 may be selected to getmenu 70. New clients may be added or deleted with buttons 78 and 79,respectively, for purposes of aggregation or disaggregation.

FIGS. 5-7 are diagrams of screens 81-83, respectively, which show howaggregated participants may be referenced and used in a variety ofrepresentative reports that are generated within the DRMS. One may notethat a “Data Source” panel 85 on the left of screens 81-83 may allow auser to select either aggregated participants or single participants,but how they are represented in a report may be different. Screen 81 mayindicate a use of aggregated participants in a report. Screen 81 may beof a “Reports TAB” with a “Filters” window 84. A row of buttons 95, 96,97 and 98 may represent selections of “Client Status”, “Events”, “Usage”and “Participation”, respectively. Button 95 may be selected for screen81. Time/Date Range 94 for start and end dates and start and end timesmay be shown below Data Source 85.

Data Source 85 shows a hierarchy of entities, such as stores, which maybe illustrative examples, for screens 81-83. The levels of hierarchy maybe level 91 with ACME Department Stores, level 92 with Store 1 and Store2, and level 93 with DRAS Client 1, DRAS Client 2 and DRAS Client 3 ofStore 1 and DRAS Client 1 of Store 2. Store 1 appears to be selected.Store 1 may be regarded as a parent and aggregation of DRAS Clients 1, 2and 3, and as a child of ACME Department Stores.

FIG. 6 is a diagram of a screen 82 of a usage report showing aggregatedusage for a Store 1. For instance, selecting an aggregated participantmay result in a usage graph that is the sum of all the participantswhich belong to the aggregated participant.

FIG. 7 is a diagram of screen 83 that shows how selecting an aggregatedparticipant may result in each individual participant appearing in thereport. In this Figure, a case is shown where selecting an aggregatedparticipant may result in each of the single participants, belonging tothe aggregated participant, showing up in the report, in contrast to thediagram of FIG. 6.

Screens 81-83 also contain a block 101, the contents of which may bedetermined by the selection of one of the buttons 95, 96, 97 and 98. InScreen 81, with button 95 selected, block 101 shows a table 102,entitled “DRAS Client Offline Statistics”, having headings of client, #times, total time (min), % time and % during events. Examples of clientsmay include 1.1 and 1.2 followed by 0 and 0, 10 and 10, 5 and 5, and 2and 2, under the headings # times, total time, % time an % duringevents, respectively. Clients 1.1 and 1.2 may be regarded as DRASClients 1 and 2 of Store 1.

Also in block 101 of screen 81 is a table 103 entitled “OfflineInstances” with headings of client, date/time offline and duration(min). Examples of clients here may include 1.1 and 1.2, timeinformation Sun June 13 14:12:33 GMT-0700 for each client, and 20 and 35minutes under the headings client, date/time offline and duration,respectively.

Screen 82 of FIG. 6 shows a button 97 selected by a cursor 104 resultingin block 101 having a table 105 and graph 106. Data Source with block 85appears the same as in screen 81. The date/time range 94 may show a dateof February 1. Table 105 may have headings of Baseline with subheadingsof Avg (kW) and Total (k . . . ), Actual with subheadings of Avg (kW)and Total (k . . . ), and Shed with subheadings Avg (kW) and Total (k .. . ). At the left of the data of the headings is a time span of anentire day and during event within the day. The data, for the entireday, show 50 and 1200 kW for avg and total, respectively, for baseline;45 kW and 1080 kW for avg and total, respectively, for actual; and 5 kWand 55 kW for avg and total, respectively, for shed. The data, forduring the event, show 120 kW and 480 kW for avg and total,respectively, for baseline; 100 kW and 400 kW for avg and total,respectively, for actual usage; and 20 kW and 80 kW for avg and total,respectively, for shed.

Graph 106 may show kW versus hours for a plot 107 of baseline data and aplot 108 of actual usage. Plots 107 and 108 appear to reveal a responseto an event during a time span 109 from the 13th to the 17th hour.

Screen 83 of FIG. 7 shows a button 98 selected by cursor 104 resultingin block 101 having a table 111 revealing an “Event ParticipationReport” for “ACME Department Stores” as selected in block 85 whichreveals the same hierarchy as in screens 81 and 82. Date/Time/Range 94may reveal a start date of February 1 and an end date of June 14.

Table 111 has headings of “Client”, “Program”, “Event”, “Date” and“Status”. The client heading lists the clients aggregated as shown inData Source block 85; however, a partial listing appears to be revealedin block 85 since one may need to scroll down to see rest of the listingof the stores and clients. Examples of data in report 111 under therespective headings for the seven lines may incorporate: Store 1.1, DBP(demand building program), 737, April 16 and OPT OUT in line 1; Store1.1, CPP (critical peak pricing), 1245, March 24 and 100% in line 2;Store 1.2, CPP, 1245, March 24 and 100% in line 3; Store 1.3, CPP, 1245,March 24 and 100% in line 4; Store 2.1, CPP, 1245, April 16 and OPT OUTin line 5; Store 3.1, CPP, 1245, March 24 and OFFLINE in line 6; andStore 3.3, DBP, 737, April 16 and OPT OUT in line 7.

In screens 81, 82 and 83, one may export information by clicking withcursor 104 on an export report button 113, an export usage data button114 and an export participation report button 115, respectively.

To recap, a demand response management system may incorporate a utilityand/or an independent service operator (utility) and two or more demandresponse (DR) resources connected to the utility. The utility mayperform an aggregation of the two or more DR resources into one entity.The utility may send DR signals as one communication from the one entityto the two or more DR resources. The two or more DR resources may sendDR resource information signals which are received by the one entity atthe utility.

The aggregation of the two or more DR resources may be effected at theutility before a DR event is initiated, and/or a DR signal is generated.If a utility issues a DR event via the one entity, then the DR event mayautomatically be propagated as DR signals to the two or more the DRresources.

The DR signals and DR resource information signals may be conveyed via acommunications channel. The communications channel may incorporate oneor more media selected from a group consisting of a network, cable,internet, satellite, wireless medium, wire medium, and other media.

The DR signals may incorporate business level information. The businesslevel information may have one or more items of a group consisting ofprices, reliability factors, shed levels, critical consumption periods,and/or other items of such information. The business level informationmay be for developing a DR program. The DR program may be a basis forthe utility to influence load profiles of the DR resources whichparticipate in the DR program at critical consumption periods on a grid.The critical consumption periods may be referred to as DR events.

Loads of a DR resource may be affected by DR events via DR signals towhich the DR resource automatically responds. The utility may send a DRsignal specific to a DR event to influence a load profile of the DRresource to ameliorate a detected level of a power commodity occurringduring the critical consumption period.

An approach for managing demand response resources may incorporateproviding a utility/ISO, providing two or more demand response (DR)resources, aggregating the DR resources into one DR resource at theutility/ISO, providing a DR event, and generating DR signals from the DRevent for the one DR resource. The approach may further incorporatereceiving DR resource information at the utility. The DR resourceinformation may have DR resource information from the two or more DRresources.

The DR signals at the utility/ISO may be designed for the one DRresource. The DR signals may be disaggregated at the one DR resource forconveyance to the two or more DR resources.

The DR resource information may incorporate business level information.The business level information may have one or more items of a groupconsisting of prices, reliability factors, shed levels, criticalconsumption periods, and/or other items of such information.

The one DR resource may be a parent participant to the two or more DRresources. The two or more DR resources may be child participants to theone DR resource. The parent participant may be an aggregated node. Theaggregated node may be a parent node. The child participants may beregarded as child nodes. The parent node may aggregate virtually all ofthe information contained within the child nodes. The parent node may bea first level of a hierarchy. The child nodes may be a second level ofthe hierarchy.

The approach may incorporate adding one or more levels to the hierarchy.An additional level may be added to the hierarchy having one or morechild nodes relative to the one or more nodes of a previous level of thehierarchy. The one or more nodes of the previous level of the hierarchymay be one or more parent nodes to the one or more child nodes of theadditional level of the hierarchy.

The hierarchy may be represented by a structure of folders. The parentnode may be represented as a first folder. The child nodes of the parentnode may be represented by a plurality of folders, respectively, withinthe first folder.

A system for managing demand response resources may incorporate autility/ISO and a first set of two or more demand response (DR)resources. The two or more DR resources may be aggregated into an entityat the utility/ISO. A DR event may be determined at the utility/ISO. DRsignals may be developed at the utility/ISO from the DR event for theentity. The DR signals may be conveyed from the entity to the two ormore DR resources. DR resource information may be conveyed from the twoor more resources to the entity. The DR resource information may beaggregated at the entity by the utility/ISO. The information aggregatedat the entity by the utility may contain virtually all of theinformation provided by the two or more DR resources.

The system may further incorporate a second set of two or more DRresources. The second set of the two or more DR resources may beaggregated by at least one DR resource of the first set of the two ormore DR resources.

The entity may be a parent participant relative to the first set of thetwo or more DR resources. The DR resources of the first set of the twoor more DR resources may be child participants relative to the entityand be parent participants of DR resources of the second set of DRresources. The DR resources of the second set of DR resources may bechild participants of at least one of the DR resources of the first setof DR resources.

A parent participant of DR resources may incorporate an aggregation ofthe DR resources. A child participant of DR resources may be a part ofan aggregation of the DR resources at a parent participant. The entity,the first set of DR resources and the second set of DR resources may beorganized as three levels of a hierarchy of participants. The system maybe expanded by incorporating additional DR resources organized asadditional levels of the hierarchy.

An application which is relevant to the present application is U.S.patent application Ser. No. 12/245,560, filed Oct. 3, 2008, and entitled“Critical Resource Notification System and Interface Device”, whichclaims the benefit of U.S. Provisional Patent Application No.60/977,909, filed Oct. 5, 2007. U.S. patent application Ser. No.12/245,560, filed Oct. 3, 2008, is hereby incorporated by reference.U.S. Provisional Patent Application No. 60/977,909, filed Oct. 5, 2007,is hereby incorporated by reference.

In the present specification, some of the matter may be of ahypothetical or prophetic nature although stated in another manner ortense.

Although the present system and/or approach has been described withrespect to at least one illustrative example, many variations andmodifications will become apparent to those skilled in the art uponreading the specification. It is therefore the intention that theappended claims be interpreted as broadly as possible in view of theprior art to include all such variations and modifications.

What is claimed is:
 1. A method for managing demand response resources,comprising: providing a utility/Independent Source Operator (ISO);providing a first set of two or more demand response (DR) resources;aggregating the DR resources into one DR resource at the utility/ISO;providing a DR event; generating DR signals from the DR event for theone DR resource; and providing a second set of two or more DR resources;wherein: the DR signals are conveyed from an entity to the two or moreDR resources; DR resource information is conveyed from the two or moreresources to the entity; the DR resource information is aggregated atthe entity by the utility/ISO; and the second set of the two or more DRresources are aggregated by at least one DR resource of the first set ofthe two or more DR resources; and wherein: the DR signals at theutility/ISO are designed for the one DR resource; and the DR signals aredisaggregated at the one DR resource for conveyance to the two or moreDR resources.
 2. The method of claim 1, further comprising: receiving DRresource information at the utility; and wherein the DR resourceinformation comprises DR resource information from the two or more DRresources.
 3. The method of claim 1, wherein the DR resource informationcomprises: business level information; and wherein the business levelinformation comprises one or more items of a group consisting of prices,reliability factors, shed levels, critical, and consumption periods. 4.The method of claim 1, wherein: the one DR resource is a parentparticipant to the two or more DR resources; the two or more DRresources are child participants to the one DR resource; the parentparticipant is an aggregated node; the aggregated node is a parent node;the child participants are child nodes; the parent node aggregatesvirtually all of the information contained within the child nodes; theparent node is a first level of a hierarchy; and the child nodes are asecond level of the hierarchy.
 5. The method of claim 4, furthercomprising: adding one or more levels to the hierarchy; and wherein: anadditional level added to the hierarchy comprises one or more childnodes relative to the one or more nodes of a previous level of thehierarchy; and the one or more nodes of the previous level of thehierarchy are one or more parent nodes to the one or more child nodes ofthe additional level of the hierarchy.
 6. The method of claim 4,wherein: the hierarchy is represented by a structure of folders; theparent node is represented as a first folder; and the child nodes of theparent node are represented by a plurality of folders, respectively,within the first folder.
 7. A system for managing demand responseresources, comprising: a utility/ISO; a first set of two or more demandresponse (DR) resources; and a second set of two or more DR resources;and wherein: the first set or the second set of the two or more DRresources are aggregated into an entity at the utility/ISO; a DR eventis determined at the utility/ISO; DR signals are developed at theutility/ISO from the DR event for the entity; the DR signals areconveyed from the entity to the two or more DR resources; DR resourceinformation is conveyed from the two or more resources to the entity;the DR resource information is aggregated at the entity by theutility/ISO; and the second set of the two or more DR resources areaggregated by at least one DR resource of the first set of the two ormore DR resources; and wherein: the DR signals at the utility/ISO aredesigned for the one DR resource; and the DR signals are disaggregatedat the one DR resource for conveyance to the two or more DR resources.8. The system of claim 7, wherein the information aggregated at theentity by the utility contains virtually all of the information providedby the two or more DR resources.
 9. The system of claim 7, wherein: theentity is a parent participant relative to the first set of the two ormore DR resources; the DR resources of the first set of the two or moreDR resources are child participants relative to the entity and areparent participants of DR resources of the second set of DR resources;and the DR resources of the second set of DR resources are childparticipants of at least one of the DR resources of the first set of DRresources.
 10. The system of claim 9, wherein: a parent participant ofDR resources comprises an aggregation of the DR resources; a childparticipant of DR resources is a part of an aggregation of the DRresources at a parent participant; and the entity, the first set of DRresources and the second set of DR resources are organized as threelevels of a hierarchy of participants.
 11. The system of claim 10,further comprising additional DR resources organized as additionallevels of the hierarchy.